A business object is a software model representing real-world items used during the transaction of business. For example, a business object may represent a business document such as a sales order, a purchase order, or an invoice. A business object may also represent master data objects such as a product, a business partner, or a piece of equipment. Particular ones of such master data objects (e.g., SalesOrder SO435539, ACME corporation) are represented by instances of their representing business object, or business object instances.
A business object may specify business logic and/or data having any suitable structure. The structure of a business object may be determined based on the requirements of a business scenario in which the business object is to be deployed. A business application for a particular business scenario may require many business objects, where the structure of each business object has been determined based on the requirements of the particular business scenario.
A business process platform, or application platform, typically exposes a complex business object model, which will be referred to herein as the platform model. The platform model describes many business objects, their relations and dependencies. The platform model may be used by several business applications, or solutions, to access data and logic of business object instances. The applications, in turn, provide such data to end-users through user interfaces, reports, etc.
FIG. 1 is a block diagram of a conventional system. Platform 110 includes platform model 120, represented here by business object BO1 and business object BO2. Each business object exposes properties, some of which are related to another property via a specified cardinality. Solution 1 and Solution 2 are business applications developed based on platform model 120. For example, Solution 1 may comprise a user interface layer to provide user interfaces to end users, while Solution 2 may comprise a reporting layer for providing reports and analytics.
Direct exposure of a platform model to an application developer can be problematic. The complexity of the platform model provides flexibility in developing applications, but much of the complexity, which includes business and technical information, may be irrelevant to the application being developed. Consequently, although Solution 1 and Solution 2 may be directed to a same field of use, each application must constrain platform model 120 to the particular parameters of the field of use.
For example, platform model 120 may allow association of an employee with any number of work agreements (i.e., a 1 . . . n cardinality). However, a particular field of use may require this relationship to be limited to exactly one work agreement per employee (i.e., a 1 . . . 1 cardinality). Accordingly, this limitation must be implemented in Solution 1 and, independently, in Solution 2. Development of each application therefore requires restriction and simplification of the complete platform model according to the model needs of the application.
A platform model also associates information with a navigation path originating at the root node of a business object. Some information, such as a contact telephone number associated with a SalesOrder business object, may be associated with a long and cumbersome navigation path. Unfortunately, Solution 1 and Solution 2 must each use reference this entire navigation path each time a contact telephone number is referenced. Similar inefficiencies exist in the referencing of separate but related data (e.g., address data).
Moreover, the consuming business applications (e.g., Solution 1 and Solution 2) are not provided with fine-granular lifecycle management for the platform model with defined lifecycle statuses (e.g., released, deprecated, etc.).